International distribution of mobile devices is complicated by the need to provide support for different languages. Such support is often referred to as National Language Support (NLS). NLS provides culture-sensitive and locale-sensitive information such as regional settings, calendar information, and date/time formatting. However, NLS is more than merely converting a system to a second language.
To support a national language, a universal device must be adaptable to any particular market or locale. A NLS device must operate with immunity from any problems that arise due to the use of different sets of characters or words. Such a system must include facilities to render the interacting characters or words different for each language.
NLS capable devices have been produced that allow manufacturers to readily install each set of characters and to efficiently change from one set of characters to another set of characters. Currently, for Windows CE and Windows Mobile, this information is contained in a ROM-based file that cannot be updated after the device has shipped.
One particular problem with providing NLS support is being able to update the NLS file after the device has shipped. For example, a first device may be configured for English, but a second device sends an email to the first device in Chinese. In this situation, the first device cannot communicate with the second device in a familiar language. Moreover, without locale specific information, the first device may not even be able to read the message from the second device because the proper code pages are not on the first device. Accordingly, the NLS file for the first mobile must be updated or changed. To change the NLS for the first mobile device, the NLS file must be included in the base NLS file.
Accordingly, the NLS support for another language or locale is not shown until the user initiates a change to the mobile device that implements a new NLS file. Because all NLS that is likely to be used must be provided in the base NLS file, the NLS file is very large. If new locale information is merged with the original NLS file, having one monolithic language file in embedded devices may cause several problems including performance and space issues. Moreover, the computing capability of such devices is limited. Merging two pieces of NLS data, for example at boot time or at run time, take too much time. Furthermore, searching through such a large file would waste too much time thereby frustrating the user.
It is with respect to these and other considerations that the present invention has been made.